Loadstar 11

home *** CD-ROM | disk | FTP | other *** search

/ Loadstar 11 / 011.d81 / pps #24 < prev next >

Wrap

Text File | 1985-01-01 | 6.2 KB | 316 lines

PEEKs, POKEs, and SYSes -- Part 24 "VARIABLES" by Alan Gardner & Jimmy Weiler ====================================== Location: 45-46 Hexadecimal: $2d-2e Official label: VARTAB Type:RAM Useful BASIC commands: PEEK, POKE -------------------------------------- Location: 47-48 Hexadecimal: $2f-30 Official label: ARYTAB Type:RAM Useful BASIC commands: PEEK, POKE ====================================== What do you suppose REALLY happens, deep down in the computer's memory when you equate variables to values, like this? 100 XY=598.345:B%=17:C$="TRY AGAIN.." Really? OOFDA! That sounds pretty complicated. We thought so, too. Jimmy and I decided to check it out. Here's what we found. The Commodore 64 stores data just like most other microcomputers. Text, color, keyboard, KERNAL, and graphics are usually cut and dried -- the function of any location is always the same. For example, your text screen usually starts at memory address 1024. Variables, on the other hand, can be found in nearly every part of BASIC RAM. BASIC RAM is the free memory from about 2049 (just above the text screen) to 40960 (the BASIC ROM). (LOOK OUT!!! IT'S CHART TIME!) Locations to peek. What they point to. -------------------------------------- 43,44 start of basic program 45,46 start of simple variables 47,48 start of array variables 49,50 end of array variables+1 51,52 end of strings 55,56 start of strings -------------------------------------- Because programs and variables can be anywhere in 38000+ bytes of RAM, your computer needs to keep track of where they are at any time. It does this by means of pointers. A pointer is nothing more complicated than a memory location that contains the address of ANOTHER memory location. (Gosh! More gobbledygook!) Okay.... It's a lot like the address on an envelope. You don't live on the envelope, you live at the address referred to by the envelope. Likewise, a BASIC program lives at the address referred to by memory locations 43 and 44, and memory locations 45 and 46 point to the address where storage of BASIC variables begins. Since one location can only hold a value between 0 and 255, two locations must be used to give an address between 0 and 65535. Location 45 is the low byte and 46 is the high byte of that address. To find the actual address of the start of BASIC variables, do the following: 200 AD=PEEK(45)+PEEK(46)*256 Now that we know WHERE the variables are stored, lets find out HOW they are stored. All simple variables are stored, in the order they are first used, from VARTAB (the start of variables) to ARYTAB (the start of arrays). As you use new variables, they push ARYTAB up through memory. Each simple variable takes seven bytes of memory between VARTAB and ARYTAB. (Waddya mean only seven bytes!? What about a string 93 characters long? How do you fit THAT into seven measley bytes?!) <Well, um, we'll get to that later (really!!).> After executing this line of code 10 XY=598.345 :B%=17 :C$="TRY AGAIN.." variable space would look something like this: ARYTAB ---> -------------- string pointer 128 third VARTAB+14-> 067 = "C" variable -------------- value of B 128 second VARTAB+7--> 194 = "B" variable -------------- value of X 089 = "Y" first VARTAB ---> 088 = "X" variable -------------- - - - - - - - - - - - - - - - - - - - Now, let's look at the three different types of variables. These types are: INTEGER, STRING, and REAL. First of all, the INTEGERS. The first two bytes of an integer variable are the name. For an integer variable, the high-bits of both bytes of the name are set. That means you subtract 128 from each byte to find the actual name of the variable. If the variable name has only one letter, byte two equals 128. Bytes three and four are the high and low bytes of the integer variable's value. Since integers values never go beyond -32767 or +32767, you only need two bytes to represent their values. Integers are stored in the unusual scheme of hi-byte first, lo-byte last. Let's break those two bytes into bits to see how some integers are stored. We'll look at 260, and -128, and -1. BINARY REPRESENTATION OF INTEGERS: byte 3 byte 4 8 7 6 5 4 3 2 1 0 8 7 6 5 4 3 2 1 0 ------------------------------------ A:0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 B:1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 C:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 There is NO escape from gobbledygook! Example A is the value 260. This one is pretty simple. Byte 3 is the high byte, so multiply its value by 256. (256*1=256.) Byte 4 is the low byte, so add its value to the result from byte 3. (256+4=260.) Example B is the value -128. Negative numbers are a bit more complicated than positives, but not too hard once you know how they work. Bit 8 of byte 3 is the "SIGN BIT". If this bit is a zero the integer is positive, if it is one, the integer is negative. If the integer is negative, it is stored in what is called "TWOS COMPLEMENT" representation. To decode a negative number, change every 1 to a 0 and every 0 to a 1, and add 1 and change the sign. (Everybody remember how to add in binary?) It goes something like this: Reverse.. 11111111 10000000 Which ----------------- gives you.. 00000000 01111111 Add 1.. +1 ----------------- 00000000 10000000 = -128 Example C works just like example B. Reverse.. 11111111 11111111 Which ----------------- gives you.. 00000000 00000000 Add 1.. +1 ----------------- 00000000 00000001 = -1 The last three bytes of an integer variable are unused, but they still need to be there. EVERY simple variable uses 7 bytes, like we said before. The seven bytes of variable storage generated by the statement B%=17 are: 194, 128, 000, 017, 000, 000, 000 < name > <value > < unused > --------<continued in part 25>--------